Electronic circuits, such as integrated microcircuits, are used in a variety of products, from automobiles to microwaves to personal computers. Designing and fabricating microcircuit devices typically involves many steps, sometimes referred to as the “design flow.” The particular steps of a design flow often are dependent upon the type of microcircuit, its complexity, the design team, and the microcircuit fabricator or foundry that will manufacture the microcircuit. Typically, software and hardware “tools” verify the design at various stages of the design flow by running software simulators and/or hardware emulators. These steps aid in the discovery of errors in the design, and allow the designers and engineers to correct or otherwise improve the design. These various microcircuits are often referred to as integrated circuits (IC's).
Several steps are common to most design flows. Initially, the specification for a new circuit is transformed into a logical design, sometimes referred to as a register transfer level (RTL) description of the circuit. With this logical design, the circuit is described in terms of both the exchange of signals between hardware registers and the logical operations that are performed on those signals. The logical design typically employs a Hardware Design Language (HDL), such as the Very high speed integrated circuit Hardware Design Language (VHDL). The logic of the circuit is then analyzed, to confirm that it will accurately perform the functions desired for the circuit. This analysis is sometimes referred to as “functional verification.”
After the accuracy of the logical design is confirmed, it is converted into a device design by synthesis software. The device design, which is typically in the form of a schematic or netlist, describes the specific electronic devices (such as transistors, resistors, and capacitors) that will be used in the circuit, along with their interconnections. This device design generally corresponds to the level of representation displayed in conventional circuit diagrams. The relationships between the electronic devices are then analyzed, often mathematically, to confirm that the circuit described by the device design will correctly perform the desired functions. This analysis is sometimes referred to as “formal verification.” Additionally, timing verifications are often made at this stage, by for example simulating the various clocks employed to drive the device.
Once the components and their interconnections are established, the design is again transformed, this time into a physical design that describes specific geometric elements. This type of design often is referred to as a “layout” design. The geometric elements, which typically are polygons, define the shapes that will be created in various layers of material to manufacture the circuit. Typically, a designer will select groups of geometric elements representing circuit device components (e.g., contacts, channels, gates, etc.) and place them in a design area. These groups of geometric elements may be custom designed, selected from a library of previously-created designs, or some combination of both. Lines are then routed between the geometric elements, which will form the wiring used to interconnect the electronic devices. Layout tools (often referred to as “place and route” tools) are commonly used for both of these tasks.
As indicated, device verification often takes place prior to the actual manufacturing of the device. As a result, hardware description languages are typically employed to model the hardware and act as an embodiment for testing purposes. However, testing and verification of physical devices also occurs after manufacturing. For purposes of brevity and clarity, a distinction between verification at the design level and at the physical level is not always made in the balance of this disclosure. Furthermore, the term device may be used interchangeably to refer to a physical embodiment of the device as well as to models or other representations of the device.
Clock Domain Crossing Verification
As stated, verification of the timing of a device often takes place during device development. The speed with which components in a circuit process signals is dictated or “driven” by a clock. Modern circuits may have multiple clocks. For example, a modern microprocessor may have a clock that allows for performance at maximum speed as well as a second clock that allows the device to perform at a reduced speed. Due to the flexibility of modern designs, multiple clocks are often required. The number of clocks in a given design is further increased by the fact that modern circuits are decreasing in size exponentially, which has allowed designers to add an increased number of circuit components into a design of a given size. This is especially true in the realm of System-on-Chip (SOC) devices.
A System-on-Chip is a microcircuit device that contains blocks or “systems” for performing various tasks, packaged as a single device. System-on-Chip devices are prevalent in modern electronics, such as cell-phones, digital video disk (DVD) players, video game consoles, household appliances, automobiles, and telecommunications equipment. Typically, a System-on-Chip is composed of blocks specifically designed to perform a particular task. These blocks are all interconnected by some communication structure, such as a shared communication bus or even a Network-on-Chip (NoC).
The components or blocks of a circuit are driven by a particular clock or a particular clock frequency. A clock having a particular frequency or speed is often referred to as a clock domain. More particularly, a clock domain is a circuit component or group of components driven by a clock or even a group of clocks that have a fixed phase relationship to each other. Clocks that are asynchronous to each other belong to different clock domains. Similarly, components driven by asynchronous clocks are said to belong to different clock domains.
Electronic signals may originate from one clock domains and be conveyed or transferred to a different clock domain, by for example signal sampling. A signal that originates in a different clock domain than it is received in, is said to be a clock domain crossing (CDC) signal. Designs where multiple clock domain crossings occur have historically been difficult for designers to verify. Traditionally, clock domain crossing verification techniques consisted of either verifying clock domain crossing signals during static timing analysis (STA) or by running gate-level simulations. Traditional clock domain crossing verification is discussed in detail in The Anomalous Behavior of Flip-Flops in Synchronizer Circuits, by W. Fleischhammer and O. Dortok, IEEE Transactions on Computers, Vol. 28, pp. 273-276, 1979, Synthesis and Scripting Techniques for Designing Asynchronous Clock Designs, by C. Cummings, SNUG, 2001, and Fourteen Ways to Fool Your Synchronizers, by R. Ginosar, ASYNC, 2003, which articles are incorporated entirely herein by reference.
As the number of clock domain crossing signals w ithin a design grows (modern designs may contain or more clock domain crossing signals), traditional techniques are often insufficient to completely verify the clock domain crossings within a device design. Traditional techniques often fail to provide exhaustive coverage of clock domain crossing violations for designs of this magnitude. Furthermore, traditional techniques are dependant on the quality of the simulation vector provided by the verification engineer. Another drawback to traditional techniques is that clock domain crossing violations, often referred to as “bugs” in the design, are found at a late stage of verification and design development. Bugs are very costly to fix at this stage of the design, as designers must again perform all the steps necessary to generate and verify a gate-level netlist from a register transfer level netlist.
Some clock domain crossing techniques that go beyond static timing analysis and gate-level simulation have been proposed. These are discussed in Using Assertion-Based Verification to Verify Clock Domain Crossing Signals, by Chris Kwok et al, DVCon, 2003, Verifying Synchronization in Multi-Clock Domain SoC, by T. Kapschitz, DVCon, 2004, and Designing a Safe Multi-Clock Chip with Clock Intent Verification, by J. Littlefield, DVCon, 2004, which articles are incorporated entirely herein by reference. However, these techniques are still insufficient to perform exhaustive clock domain crossing verification. This is especially true for large designs, where the number of clock domain crossing signals is increasing exponentially in parallel with the increasing number of clock domains. Particularly troubling is the fact that multiple iterations of verification and error correction in the design flow are required to completely resolve all clock domain crossing violations.